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RELATED APPLICATIONS 

This application is a continuation of U.S. Application Serial No. 
09/507,480, filed February 17, 2000 and entitled "Automatic Baud Rate Detection 
of Null Modem Unimodem Client Connection", incorporated by reference herein 
for all that it discloses and teaches. 

TECHNICAL FIELD 

This invention relates to computer operating systems, and particularly, to 
computer methods for detecting baud rates for communicating with client devices 
over a serial null modem connection that uses a Unimodem null serial protocol. 

BACKGROUND 

Handheld computing devices have grown rapidly in popularity in recent 
years. These devices enable users to port many of the tools and features of their 
desktop computers on excursions away from home or the office. While these 
devices offer tremendous advantages for portability, most mobile users still rely on 
desktop computers when working at home or the office. 

As a result of operating multiple computers, users often enter different 
information into different computers depending upon their situation and location. 
For instance, a user may enter tasks or other data into a work computer, 
appointments and contact information into a portable computer while on the road, 
and calendar events into a home computer when at home. Yet, when the user 
wants to see their schedule, the user wants to view the most up-to-date schedule, 
regardless of where the information was entered or where the user accesses it. 
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To avoid making the user enter the same data multiple times into different 
computers, most handheld computers are configured to swap information with 
desktop computers. Programs executing on one or both computers synchronize the 
exchange of schedules, appointments, and other data contents so that any unique 
information currently residing on one of the computers is shared with the other to 
bring both computers up to-date. 

Typically, handheld computers connect to a host desktop computer via a 
serial connection. One common serial connection is known as a "null modem 
connection", which uses a Unimodem null serial protocol to exchange data. 
According to this protocol, the handheld computer initiates communication by 
sending a message called "CLIENT". The host computer replies with a message 
"S", "E", "R", "V", "E", "R", "C", "L", T\ "E", "N", "T". If both sides 
understand the transmission, a synchronization session is begun to synchronize the 
contents of the two computers. 

One problem surrounding this serial protocol is that the message exchange 
is baud rate dependent. That is, both the handheld computer and the host computer 
must be operating at the same baud rate for each to understand the other's 
message. However, there are many different baud rates at which the two 
computers may communicate. For example, handheld computers that run the 
Windows CE operating system from Microsoft Corporation can support four 
different baud rates: 19.2K, 38K, 56K, and 115K. If the handheld computer is 
operating at one baud rate (e.g., 19.2K) and the host computer is operating at 
another baud rate (e.g., 56K), the two computers will not be able to communicate 
with one another. Unfortunately, connection failures due to serial baud rate 
mismatches tend to be common. 
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When a baud rate mismatch occurs, the user typically tries to adjust the 
baud rate of one of the computers. It tends to be harder to change the baud rate on 
the host computer, so the user generally ends up manually reconfiguring the 
handheld computer to a different baud rate. 

Another problem is that an increasing number of users own more than one 
handheld computer. In some cases, the handheld computers may be set to different 
baud rates, whereas the host computer can be set to only one of these baud rates at 
a given time. As a result, the user is forced to adjust baud rates more often to 
accommodate the multiple portable devices. 

Thus, there is a need for an improved system and method for connecting 
handheld computers to host computers over a null modem unimodem client 
connection. 

SUMMARY 

This invention concerns a baud rate detection system and method for 
automatically detecting the baud rate at which a client computing device is 
communicating with a host computer over a serial connection. 

In one implementation, the host computer is coupled to the client computing 
device via a serial connection, which employs a Unimodem null serial protocol to 
exchange data. The baud rate detection system includes a baud rate selector to 
select among multiple baud rates that the client computing device might use to 
transmit a predefined message (e.g., a text string "C", "L", "I", "E", "N", "T"). 
The system also includes a message detector to listen at the currently selected baud 
rate for the predefined message. 
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During operation, after the client connects to the host computer, the baud 
rate selector chooses a first baud rate from among the multiple possible baud rates. 
The message detector listens at this baud rate for the message. If the message 
detector receives the message, the current baud rate is the correct rate and is used 
for continuing communications with the client computing device. On the other 
hand, if the message detector fails to detect the message after a predetermined time 
period or detects characters not included in the predefined message, the baud rate 
selector chooses a new baud rate and the message detector begins listening at the 
new baud rate. This process continues until the baud rate detection system finds 
the appropriate baud rate for communicating with the client computing device. 

The automatic baud rate detection is advantageous because it effectively 
eliminates connection failures caused by baud rate mismatches. This obviates the 
need for a user to manually reconfigure either the host or client computing device 
when baud rate mismatches occur. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a block diagram of a host computer connected to a client 
computing device, such as a handheld computer. 

Fig. 2 is a flow diagram of a method for automatically detecting a baud rate 
at which the client computing device is transmitting data. 

DETAILED DESCRIPTION 

Fig. 1 shows a computer system 20 having a host computer 22 connected to 
a client computing device 24 via a serial connection 26. The host computer 22 
may be embodied in many ways including, for example, a workstation, a desktop 
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computer, a laptop computer, or the like. The client computing device 24 may also 
be implemented in a number of ways, such as a handheld computer, a telephone or 
other communication device, a personal digital assistant, and so forth. The serial 
connection 26 is preferably employs a null modem Unimodem client protocol, 
which establishes a connection between the host computer 22 and client computing 
device 24. Once the connection is established (as described below), the system 
uses known protocols such as PPP, IP, and TCP to exchange data over the serial 
connection. 

The host computer 22 has a memory 30, a processor 32, a display 34, one or 
more input devices 36 (e.g., keyboard, mouse, USB connections, etc.), and 
multiple communication (COMM) ports 38. The memory 30 generally includes 
both volatile memory (e.g., RAM) and non-volatile memory (e.g., Flash, ROM, 
hard disk, etc.). 

An operating system 50 resides in memory 30 and executes on the processor 
32. The host computer 22 preferably runs a Windows-brand operating system from 
Microsoft Corporation, such as Win32-based products (e.g., Windows 95, 
Windows 98, etc.), although other operating systems may be used. One or more 
application programs 52 are loaded into memory 30 and run on the operating 
system 50. Examples of applications 52 include email programs, scheduling 
programs, word processing programs, Internet browser programs, and so on. The 
operating system 50 has a set of drivers 54 to manage COMM ports 38, as well as 
peripheral devices connected through the COMM ports and/or various hardware 
components. 

The operating system 50 has a synchronization module 58 to facilitate serial 
communication between the host computer 22 and the client computing device 24 
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and to synchronize the contents on each machine. The applications 52 call the 
synchronization module 58 via an API (application programming interface). For 
instance, a scheduling program on the host computer 22 calls the synchronization 
module 58 to facilitate the exchange of appointments and tasks between the two 
computers to bring both computers up to date. As an exemplary implementation, 
the synchronization module 58 is implemented as part of the Windows CE 
Services module in the Windows CE operating system. 

The synchronization module 58 is configured to facilitate serial 
communication using the Unimodem null serial protocol. According to this 
protocol, the client computing device 24 initiates a communication session by 
sending over a message consisting of the text string "C", "L" "I", "E", "N" T 
and the host computer 22 replies with a message ""S", "E", "R" "V", "E" "R", 
"C", "L", "I", "E", "N", "T"". As part of the configuration, the synchronization 
module 58 implements a baud rate detection system 60 that automatically detects a 
baud rate at which the client computing device 24 is transmitting data. The baud 
rate detection system 60 automatically cycles through a set of possible baud rates 
and at each rate, listens to detect the message text string "C" "L", "I", "E" "N", 
"T" from the client computing device 24. 

The baud rate detection system 60 includes a rate selector 62, a message 
detector 64, and a rate cache 66. The rate selector 62 selects among multiple baud 
rates at which the client computing device may transmit the message over the 
serial connection. The baud rates may be stored, for example, in a table 68. 

Once a baud rate is selected, the message detector 64 listens to the serial 
channel at the selected baud rate. If no message is received within a 
predetermined time period, or only error characters are received (i.e., characters 
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not in the message "C", "L", "I", "E", "N", "T"), the rate selector 62 selects a next 
baud rate from the table 68 and the message detector 64 listens to the serial 
channel at this next baud rate. Eventually, the rate selector 62 picks a baud rate 
that enables the message detector 64 to successfully receive the text string "C", 
"L'\ "I", "E", "N" "T'\ Once this occurs, the rate selector 62 sets the baud rate at 
the current rate for future communication with the client. The rate selector also 
caches the baud rate in cache 66 for use in subsequent client connects under the 
assumption that it is likely that the host computer will communicate again with the 
same client computing device at the same baud rate. This process is described 
below in more detail with reference to Fig. 2. 

With continuing reference to Fig. 1, the client computing device 24 is 
illustrated as having a processor 70, a display 72, one or more input devices 74 
(e.g., keypad, touchpad, microphone, etc.), a serial port 76, and a memory 78. The 
memory 78 represents both volatile and non-volatile memory, and is used to store 
programs 80 and an operating system 82. As an exemplary implementation, the 
operating system is the Windows CE operating system from Microsoft 
Corporation. The Windows CE operating system supports four different baud 
rates: 19.2K, 38K, 56K, and 115K. 

Fig. 2 shows a method for automatically detecting a baud rate at which the 
client computing device 24 is transmitting data. These steps are performed, for 
example, in software by the baud rate detection system 60 at the host computer 22. 

At step 100, the baud rate detection system 60 waits for the client 
computing device to connect. This connection may be a physical connection, in 
which the client computing device is attached to a serial cable or placed in a 
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cradle. The connection may alternatively be non-physical, such as an IR (infrared) 
connection or an RF (radio frequency) connection. 

Once a connection is made, the rate selector 62 determines whether there is 
a baud rate currently cached in rate cache 66 (step 102). If there is (i.e., the "yes" 
branch from step 102), the rate selector loads the cached baud rate as the current 
baud rate (step 104). If not (i.e., the "no" branch from step 102), the rate selector 
62 sets the current baud rate to a default rate identified in the baud rate table 68 
(step 106). 

At step 108, the baud rate detection system 60 checks if the client 
computing device 24 is still connected. If not, it returns to the wait state at step 
100. Assuming that client is still connected (i.e., the "yes" branch from step 108), 
the message detector 64 begins listening at the current baud rate for the "C-L-I-E- 
N-T" text string to be transmitted from the client computing device (step 110). 

At this point, there are three possibilities: (1) the host receives the correct 
message; (2) the host receives error characters that are not in the text string "C", 
"L", "I", "E", "N", T; or (3) the host receives no characters within a prescribed 
timeout period. Decision steps 1 12, 116, and 120 address these three possibilities. 
At step 112, the message detector 64 determines whether it receives the "C", "L", 
"I", "E", "N", T text string. If it does (i.e., the "yes" branch), the host computer 
22 is using the same baud rate as the client computing device 24 and hence no 
further adjustment to the baud rate is needed. The rate selector 62 caches the 
current baud rate into the rate cache 66 for future use during the next connection 
and the process is completed. At this point, the host computer 22 responds to the 
client computing device with a response message ""S", "E" "R", "V", "E", "R", 
"C", "L", "I", "E", "N", "T"", which is transmitted at the current baud rate. 



Lee & Hayes. PUC 



8 



MS# 39536.02 G:\MS1 -0\400usci\MSl-400USCI.pat.app.doc 



I 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 



Suppose, however, that the message detector 64 begins detecting error 
characters instead of the text string "C", "L", "I", "E", "N", "T" (i.e., the "no" 
branch from step 112 and the "yes" branch from step 116). Such error characters 
may occur through aliasing or other artifacts as a result of transmitting at one baud 
rate and detecting at a different baud rate. In this case, the message detector 64 
knows immediately that it is using the wrong baud rate and rate selector 64 can 
select the next baud rate in the baud rate table 68 without waiting for the timeout 
period to elapse. The process then continues at step 108. 

Next, suppose that the message detector 64 detects neither the text string 
("C", "L", "I", "E", "N", "T") nor error characters (i.e., the "no" branch from step 
112 and the "no" branch from step 116). In this case, the host computer may or 
may not be operating at a compatible baud rate. One possible explanation is that 
the client computing device has not yet sent over the message. Another possible 
explanation is that the host is indeed operating at an incompatible baud rate. To 
rule out the former explanation, the message detector 64 listens for a 
predetermined timeout period, such as 20 seconds. If the message detector 64 fails 
to detect the text string or error characters within this timeout period (i.e., the "yes" 
branch from step 120), the rate selector 62 selects the next baud rate in the baud 
rate table 68 and the process continues at step 108. 

To provide an example of this process, suppose that the client computing 
device 24 is set to a baud rate of 19.2K. In addition, suppose that the baud rate 
table 68 lists four baud rates in the following order: (1) 56K, (2) 19.2K, (3) 115K, 
and (4) 38K. The rate selector initially selects the default rate of 56K. The 
message detector 64 listens at 56K, but fails to detect the text string ("C", "L", "I", 
"E", "N", "T") being transmitted at 19.2K. Accordingly, either upon receiving 
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error characters or upon expiration of the timeout period, the rate selector 62 
automatically selects the next baud rate of 19.2K. Since this is now the baud rate 
used by the client computing device 24, the message detector 64 will detect the 
text string ("C", "L", "I", "E", "N", "T"). The rate selector 62 caches the 19.2K 
rate in cache 66 and the process is completed. 

The system and process described above is advantageous because it enables 
automatic detection of the client baud rate. As a result, connection failures caused 
by baud rate mismatches are effectively eliminated. This obviates the need for a 
user to manually reconfigure either the host or client computing device when baud 
rate mismatches occur. 

Although the description above uses language that is specific to structural 
features and/or methodological acts, it is to be understood that the invention 
defined in the appended claims is not limited to the specific features or acts 
described. Rather, the specific features and acts are disclosed as exemplary forms 
of implementing the invention. 
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